Because ASCs are unmanned, exception handling is critical. Therefore, when the ACCS receives a transport order for a crane, it first evaluates whether it is in a position to accept the order. If it accepts the order, there still may be situations in which an ASC cannot continue handling an order and needs instructions to resolve the deadlock.
Typically, a crane rejects an order based on a validation error, not because of a technical problem, and it aborts an order as a result of human interaction triggering a technical error. Is this equally valid for both supported interfaces?
|
Rejection Reason |
ACCS Reaction |
Description |
|---|---|---|
|
Invalid order state |
Order rejection |
The order is erroneous, for example because the crane's position is unknown. Ideally, the ACCS provides details about the problem. ECN4 suspends the order. |
|
Invalid ASC state |
Order rejection |
The crane is not in a state to receive the order, for example because it went offline when XPS issued the order. ECN4 resets the work instruction to make it re-available for dispatch. |
|
Cannot lift container |
Order Abortion |
The crane cannot lift the container. In most cases, this happens due to an inventory issue at the origin. If available, the ACCS provides XPS with the reason for the abort. ECN4 suspends the order so that you can verify the condition of the stack and resume work when possible. |
|
Cannot set container |
Order Abortion |
The crane cannot set down the container. In most cases, this happens due to an inventory issue at the destination. If available, the ACCS provides ECN4 with the reason for the abort. ECN4 proceeds as follows:
If the destination was a grounded transfer zone:
|